• Петлин Артём Дмитриевич
• студент
• группа НПИбд-02-24
• Российский университет дружбы народов
• 1132246846@pfur.ru
• https://github.com/hikrim/study_2025-2026_os2

Проверяем доступность внешних ресурсов через ping.

С помощью утилиты dig узнаем IP-адреса популярных сервисов.

Изменяем порт SSH и запрещаем вход по паролю.

Настраиваем подключение по ключу и авторизуемся.

Используя fail2ban, создаем jail, который будет блокировать IP-адрес после трех успешных запросов к nginx.

Удаляем утилиту htop, затем устанавливаем заново с полной очисткой (purge).

Выполняем полное обновление системы.

Настраиваем автоматическую установку обновлений безопасности.

Устанавливаем пакет вручную через dpkg, предварительно скачав его с сайта.

Просматриваем содержимое основного системного журнала и журнала аутентификации, используя утилиту для постраничного просмотра.

Генерируем тестовое сообщение с помощью утилиты logger. Затем находим это сообщение сначала в выводе journalctl, а потом в файле /var/log/syslog. Используя journalctl, фильтруем и выводим только те события, которые имеют уровень важности error (err) или более критичный. Заглядываем в конфигурационный файл rsyslog (например, /etc/rsyslog.d/50-default.conf) и находим строку, отвечающую за направление сообщений от категорий (facility) auth и authpriv в файл /var/log/auth.log. Отправляем в системный журнал сообщение с явно указанным уровнем важности warning. Убеждаемся, что оно появляется в выводе journalctl при фильтрации по этому уровню.

Находим в журнале аутентификации /var/log/auth.log все попытки входа от имени несуществующих пользователей.

Изучаем существующую конфигурацию logrotate для системного менеджера пакетов (apt или dpkg) в директории /etc/logrotate.d/. Определяем, как часто происходит ротация, сколько архивных копий хранится и используется ли сжатие.

Создаем собственный конфигурационный файл /etc/logrotate.d/testapp для управления вымышленным лог-файлом /var/log/testapp.log. Настраиваем его на ежедневную ротацию, хранение четырех архивных копий и сжатие старых логов.

Проверяем созданную конфигурацию logrotate на синтаксические ошибки, выполнив «сухой запуск» в режиме отладки.

Запускаем контейнер.

Запускаем Nginx и проверяем, что он работает.

Запускаем контейнер Nginx с ограничением памяти в 100 МБ и проверяем его работу.

Исследуем поведение контейнера при исчерпании выделенной памяти.

Создаем и запускаем кастомный веб-сайт на базе nginx с использованием Podman.

Сохраняем образ и переносим его на другой сервер.

Мы используем команду ip a add для временного добавления IP-адреса к сетевому интерфейсу. Директива auto в файле /etc/network/interfaces указывает системе, какие интерфейсы нужно автоматически активировать (поднимать) во время загрузки. Для удаления конкретного IP-адреса с интерфейса мы используем команду ip a del с указанием полного адреса с маской и имени интерфейса.

Настройки, заданные с помощью команды ip, являются временными и действуют только до перезагрузки системы. При статической настройке сети в файле /etc/network/interfaces мы указываем шлюз по умолчанию с помощью директивы gateway в блоке настроек интерфейса.

Мы используем современную утилиту ss с ключами -t , -u , -l, -n, -p для получения полного списка открытых портов и связанных с ними процессов. Ключ -p в команде ss заставляет ее отображать идентификатор процесса (PID) и его имя, которое использует данный сокет.

Мы используем команду dig для выполнения DNS-запросов и получения подробной информации о доменных именах, включая их IP-адреса. Для быстрой проверки доступности удаленного TCP-порта мы используем утилиту netcat с ключами -v и -z.

По умолчанию демон SSH-сервера прослушивает входящие подключения на TCP-порту 22. Главный файл конфигурации для серверной части SSH находится по пути /etc/ssh/sshd_config. Файл ssh_config предназначен для клиентской части. Для временной остановки системного сервиса мы используем команду systemctl stop.

Для настройки аутентификации по SSH-ключу мы копируем содержимое файла публичного ключа в файл authorized_keys на сервере. Директива PermitRootLogin no в файле /etc/ssh/sshd_config запрещает прямое подключение к серверу по SSH под учетной записью root, что является важной мерой безопасности.

После настройки правил мы активируем межсетевой экран UFW командой ufw enable. Это применяет правила и включает автозагрузку файрвола при старте системы. Основные настройки jails Fail2ban, которые определяют правила блокировки, хранятся в файле /etc/fail2ban/jail.conf. Чтобы удалить правило по его номеру из списка, выведенного командой ufw status numbered, мы используем команду ufw delete [номер].

Параметр bantime в конфигурации jail Fail2ban определяет длительность блокировки IP-адреса в секундах после превышения лимита попыток. Для ограничения доступа к порту по источнику мы используем синтаксис ufw allow from [источник] to any port [порт]. Это разрешает подключения только с указанной подсети.

Команда apt autoremove удаляет пакеты, которые были установлены автоматически как зависимости и больше не нужны. Сами целевые пакеты удаляются командой remove, а их конфиги остаются. Команда apt purge удаляет пакет вместе с его конфигурационными файлами. Зависимости, установленные с ним, при этом остаются в системе. Мы регулярно выполняем apt update, чтобы обновить локальную базу данных пакетов. Без этого система не будет знать о новых версиях пакетов.

Пакет unattended-upgrades позволяет нам настроить автоматическую установку обновлений безопасности и других пакетов без ручного вмешательства. После apt update мы выполняем apt upgrade, чтобы установить все доступные обновления для установленных пакетов. Команда apt full-upgrade выполняет более интеллектуальное обновление, которое может удалять obsolete пакеты или устанавливать новые зависимости, что иногда необходимо для полного обновления системы.

При возникновении проблем с зависимостями мы используем команду apt –fix-broken install, чтобы попытаться автоматически исправить нарушенные зависимости. Принудительное удаление пакета, от которого зависят другие программы, приводит к “разрыву зависимостей”. Для фильтрации вывода других команд и поиска конкретного пакета мы используем конвейер с grep.

Мы предпочитаем устанавливать .deb файлы через apt, так как он автоматически разрешает и устанавливает все зависимости. APT проверяет целостность и подлинность пакетов из репозиториев с помощью GPG-ключей, что защищает систему от установки модифицированных или вредоносных пакетов. В корпоративной среде, если нужного пакета нет в утвержденных репозиториях, правильным действием является запрос на его добавление через систему тикетов, а не самостоятельная установка из непроверенных источников.

Мы используем логи в первую очередь для этих трех целей: найти причину неисправности, выяснить обстоятельства взлома и определить “узкие места” в системе. Ошибка 502 обычно указывает на проблему связи веб-сервера с backend-процессом. В современных системах логи хранятся в двух основных местах: классические текстовые файлы в /var/log/ и централизованный бинарный журнал systemd, который мы просматриваем с помощью journalctl.

Обычно systemd-journald действует как первичный сборщик логов, а затем, при наличии настроек, перенаправляет сообщения в демон syslog для постоянного хранения в привычных текстовых файлах в /var/log/. Сбой запуска критичной системной службы — это значимое негативное событие, которое классифицируется уровнем error, а не просто информационным сообщением. Категория в syslog указывает на подсистему или программу-источник сообщения.

Чтобы uniq мог корректно подсчитать повторяющиеся строки, они должны следовать друг за другом. В awk $1, $2, $3 и т.д. обозначают первое, второе, третье и последующие поля в строке. Мы используем конвейер: первый grep отфильтровывает строки с “error”, а второй grep с ключом -v удаляет из этого результата строки, содержащие “healthcheck”.

Большое количество неудачных попыток входа за короткий промежуток времени, особенно для стандартных имен пользователей, является классическим признаком автоматизированной brute-force атаки. Расчет хеша фиксирует текущее состояние файла. Команды, выполненные через sudo, подробно логируются в журналах аутентификации.

Основная задача logrotate — ротация, архивация и удаление старых лог-файлов по заданному расписанию и правилам. Удаленный сбор логов обеспечивает целостность журналов. Grafana Loki спроектирован именно для этого сценария.

Команда podman info выводит подробную информацию о среде Podman: версию, конфигурацию, хранилища, сеть и т.д., что помогает нам проверить корректность его настройки. Ключевое архитектурное отличие Podman в том, что он использует архитектуру без демона. Ключ –rm автоматически удаляет контейнер сразу после того, как он завершит свою работу.

Безопасность Podman для многопользовательских сред обусловлена его способностью работать в rootless-режиме. Как уже было отмечено, Podman не требует постоянно работающего фонового демона.

Мы используем команду podman run для запуска нового контейнера. Флаг -v используется для монтирования директорий или файлов с хостовой машины внутрь контейнера. Комбинация флагов -i и -t позволяет нам запустить контейнер в интерактивном режиме с псевдо-TTY.

По умолчанию podman ps показывает только работающие контейнеры. Чтобы увидеть все контейнеры, включая остановленные, мы добавляем флаг -a. Флаг –rm заставляет Podman автоматически удалять контейнер сразу после его остановки.

Для мониторинга потребления ресурсов работающими контейнерами в реальном времени мы используем команду podman stats. Флаг -d запускает контейнер в фоновом режиме. После запуска управление возвращается в терминал, а контейнер продолжает работать независимо. После изменения unit-файлов systemd мы выполняем systemctl daemon-reload.

Когда контейнер запущен как systemd-сервис, его логи интегрируются в общий журнал systemd. Флаг –memory устанавливает максимальный лимит оперативной памяти, который может использовать контейнер.

Для загрузки Docker-образов из удаленного реестра мы используем команду podman pull. Файл policy.json определяет политику доверия для образов контейнеров. В нем мы настраиваем, из каких реестров разрешено скачивать образы, требуется ли для них цифровая подпись и какие ключи являются доверенными. Команда podman build используется для сборки собственного образа контейнера.

Мы используем podman build -t myapp . для создания собственного образа из инструкций в Dockerfile, который находится в текущей директории. Результатом будет образ с именем myapp. Если в политике доверия (policy.json) для определенного реестра или образа указана директива signedBy, то Podman будет проверять наличие и валидность цифровой подписи у образа.